系列：《我用 AI 養出一個 AWS 維運同事：30 天實戰紀錄》
作者：康子晉｜AWS 解決方案專家，守備範圍橫跨架構設計、維運排錯、成本優化與雲端遷移。
撰於 2026-09｜環境：Kiro（AWS 的 agentic IDE）IDE 1.0 版

先自首：這不是一個「AI 很神」的故事

如果你點進來是想看「用 AI 一鍵解決所有維運」，我勸你先深呼吸。

這一年我做的事，比較像「帶一個很強但很盧的新人」。他學東西超快、AWS 冷門服務對答如流，但你剛認識他的時候，他有兩個會讓你血壓飆高的毛病：一開新對話就把你忘光光，還有不會的東西也敢用超篤定的語氣唬你。

我是一個每天在巡帳號、查費用、排錯、畫架構圖的維運工程師——偶爾還得 ssh 進機房，替一台快撐不住的地端主機挖磁碟空間。我沒有時間每天重新跟一個 AI 自我介紹，更不敢把一個會唬爛的傢伙放進 production。所以我花了一年，一塊一塊幫他把這些毛病治好，直到他真的能幫我幹活。

這 30 天，就是把這套「養成過程」完整攤開來講。連我踩過的雷一起講。

先把地基交代清楚（前傳在這）

眼尖的老讀者會發現，我之前寫過一個小系列，打好了四塊地基。這一季會站在這四塊地基上往上蓋，所以我先用一張表交代它們講了什麼，讓新朋友知道「喔原來有這些前提」：

那 4 篇還在，連結放這（[前傳系列連結]），想補地基的可以先去看。但你完全可以從這裡開始讀——我不會假設你看過，需要用到前傳觀念時我都會用一兩句話帶過並附連結。

之所以要重開一季，是因為過去這半年我的 AI 同事「長大」了很多——多了一整套會自己蒸餾知識的記憶系統、一組各有專長的分身、十來個自動化的背景整理員。這些都是前傳沒講到的深水區，而它們剛好是維運人最有感的部分。

所以這一季的定位很簡單：不是教你玩 AI，是講一個維運工程師怎麼用 AI 把髒活累活做得更好。

這一季會蓋哪些樓：全景圖

地基之上，這 30 天要講的都是前傳沒寫過的新東西：

穿插在這些機制之間的，是十幾篇真實維運戰役（去識別化）——費用暴衝破案、EKS 鬼故事、DNS 迴圈、閒置資源盤點，還有幾場發生在機房裡的：一台地端主機只剩 8G 可用空間、一台 500G 的虛擬機要搬去 NAS。用來證明這個 AI 同事真的能下場幹活，不是紙上談兵。

這裡先說清楚一件事，免得你讀到後面覺得跳 tone：這一季不會只講 AWS。 因為真實的維運人生從來不是只有雲——大部分公司都是雲上雲下混著顧，你上午在調 EKS 的節點，下午就得 ssh 進地端的 ESXi 搶救磁碟空間。我的 AI 同事如果只會 call AWS API，那它就只能陪我上半天班。

這一季的紀律：我會標「版本」

先立個規矩。AWS 的配額、定價改超快，Kiro 這種工具改得更快——我前傳寫的某個 hook 語法，這半年就換過一次寫法。所以這一季每篇我都會標「撰於哪個月、基於哪個版本」，講到具體設定語法時，也會註明新舊差異。

半年後你來看，就算某個畫面、某個欄位名變了，你至少知道「喔這是 2026 年 9 月的寫法」，不會被過時的細節坑到。這也是我想傳達的第一個維運心法：寫文件（跟養 AI）都要對「時效」誠實。

帶走的三個重點

1. AI 的毛病不是模型笨，是你沒給它機制。 失憶、唬爛都能靠設計治好。
2. 這一季用「帶新人」當主線，六個動作對應六種機制，你不用背術語，記比喻就好。
3. 對時效誠實。 工具會變、雲會變，標清楚版本是專業，不是囉嗦。

明天先從那個最讓人受不了的毛病收尾——唬爛。前傳教它「先查後答」，但我後來發現光靠自律不夠，於是又請了三個「審稿員」在背後自動幫我複查。這就是我說的防幻覺 2.0。

✍️ 關於作者：康子晉，做 AWS 維運與架構，日常跟一堆帳號、費用、架構圖為伍。這個系列記錄我怎麼把 AI 從「會聊天」調教成「能扛維運的同事」。
🔗 LinkedIn